Shouldn't we wait until zig 0.14.0 is released?

Sure, can leave the mr open in any case until then maybe

@Joonsey @HaxSam when is Zig 0.14.0 being released?

I'm unfamiliar, however they do very much recommend using master.

With a release cadance every ~6 months.

I can update this PR until release if that's preferred?

Also, the zig binding from @Not-Nik (raylib-zig) only uses the latest release from zig. See CONTRIBUTING.md
To keep compatibility with the raylib build.zig it would be preferential to do the same here.

I do that so I don't have to keep updating the binding for each breaking master change, but since we JUST had a raylib release and a new Zig release is imminent it's fine to update the build.zig from my side. Zig being a very immature language forces me to switch to the -dev versions of raylib anyways, so in this I'd rather have an updated build file sooner than later :)

@Joonsey @HaxSam @Not-Nik Note that I have no problem to update the build.zig to latest Zig master branch, considering raylib master branch is the dev branch. If you agree with it, just let me know and I'm merging it.

i am okay with this as it is, if you are @raysan5.

If anything, perhaps should enforce a version compatibility check as this is a breaking change for < zig.1.14

@Joonsey Ok, let's merge it! Anyway, Zig users should probably update to v0.14 at this point...

It seems a good idea to me that raylib master should try to be compatible with zig master. It would have saved me some headaches at the start.

(I started learning zig+raylib. everyone seems to just download the first/main zig download link on the zig site. (0.13 is buried down lower on the page), no one knows to scroll down and look for 0.13. So when I downloaded zig (0.14) and raylib, raylib didn't work and it was a huge headache for a beginner. The end result was, I discovered lots of people have this same problem.)

@zaddok

It seems a good idea to me that raylib master should try to be compatible with zig master. It would have saved me some headaches at the start.

(I started learning zig+raylib.

I think there is a misunderstanding here. For raylib, the ground truth is the C Language source code. For stability reasons, using raylib master is not the best choice, unless work on raylib itself is intended. Use of stable releases (e.g., raylib 5.5) is preferable, avoiding breaking changes underway.

As to bindings for other languages and platforms, those are not managed by raylib. Binding maintainers tend to target raylib releases, not tracking the development branch of raylib. This seems to be the case for Zig bindings.

The same considerations apply to raylib-employed externals. Raylib does not track those but includes dependencies on the latest (stable?) as part of a new raylib release. If there are breaking changes on either side, more work is needed, but only then.

For learning, reliance on stable combinations is essential. Tracking masters is generally a bad idea.

I have no suggestions with regard to the tracking of a developing language though. I had enough trouble with invisible breaking changes between Python 2.x and Python 3. It was time to run away.